Fix Int? argument issues on 32-bit environments#667
Conversation
# Conflicts: # Sources/JExtractSwiftLib/JNI/JNIJavaTypeTranslator.swift
# Conflicts: # Sources/JExtractSwiftLib/JNI/JNISwift2JavaGenerator+JavaTranslation.swift # Sources/JExtractSwiftLib/JNI/JNISwift2JavaGenerator+SwiftThunkPrinting.swift
|
Sorry, I forgot to point this out; This PR requires swiftlang/swift-java-jni-core#16 to be merged first. |
|
I see... let's get some Android folks to chime in here, @madsodgaard has an interest in keeping those 32bit runtimes happy. |
|
If I'm reading this right, I do think it introduces peril for 32-bit platforms like armv7 on Android and other embedded devices. In swiftlang/swift-java-jni-core#16 (comment) I suggest simply dropping |
|
Not supporting There's tons of Swift libs out there using
I'm not sure how to be honest, can you think of something? We're widening and swift jextract actually checks for overflows; manual users of jni-core may need to do the same, but I don't see it breaking anything 🤔 |
You do not need one, as most 64-bit Android devices support 32-bit execution, as does the emulator I believe. Simply run the 32-bit code and libraries in a 64-bit runtime and it should just work. |
|
The actual question here is what we "want" tbh... I could rebase the work but I'm not sure what we want to do here tbh still... The OP is on leave for a while AFAIR, so we'd need to take this over. |
|
The purpose of this PR is the following Swift code can be correctly handled in 32-bit env. public func optionalPlatformDependentInt(input: Int?) -> Int? {
input
}At the time of submission, it caused several compilation errors (though I'm not sure about its current status). |
|
And the root cause of this issue is swiftlang/swift-java-jni-core#16 , which needs to be resolved first. |
|
I’ll give all this another look, maybe it’s fine to just merge that one hmm |
This PR fixes issues related to
Int?arguments on 32-bit architectures.The generated code contained numerous errors. (The failing CI run: https://github.com/swiftlang/swift-java/actions/runs/23786261629/job/69318324924 )
Background
During my investigation, I realized that the dynamic nature of
Int.JNITypewas significantly complicating the logic.I have already submitted a PR to address this: swiftlang/swift-java-jni-core#16
In this PR, I have removed the various implementation pieces that were previously used to manually wrap
IntintoInt64.With the unified
JNIType, these are no longer necessary, and removing them resolves the original problem.Verification
I have verified that the generated code compiles correctly for 32-bit by running the following command in SwiftJavaExtractJNISampleApp:
./gradlew assemble -PswiftSdk=armv7-unknown-linux-android28While the compilation is successful, I do not have a 32-bit Android runtime environment, so I haven't been able to verify the actual execution results.